iT邦幫忙

2024 iThome 鐵人賽

DAY 10
0
Software Development

Event driven architecture的奧妙系列 第 10

Day 10 - Synchronous v.s Asynchronous

  • 分享至 

  • xImage
  •  

前言

前幾天我們花了一些時間分別講Synchronous和Asynchronous:

  • 運作流程
  • 優缺點
  • 應用場景

有用實際的例子讓大家瞭解。
今天我們整理成表格的形式,通過表格讓大家更加明白兩個方法的區別。

好了~我們開始吧!

Synchronous vs Asynchronous

前幾天有舉銀行開戶的範例給大家理解,本篇會再舉一個例子讓各位複習一下:

假設你是老闆,今天要負責訂員工們的午餐,但因為你是老闆,所以你使用發包之力(XD):

如果你使用syn的方法發包:

  1. 你叫員工A過來,請他去買午餐
  2. 當員工A出去買午餐時,你就在門口等到他買完回來
  3. 接著再叫員工B過來,請他去買飲料
  4. 員工B出去買飲料,你一樣在門口等他買完回來

等員工B買完飲料回來,便當早就涼了,你因為這樣氣pupu。
這樣的運作模式顯然是有問題的,問題在於員工A出去買的時候你需要在門口"等待"他回來才能繼續發包任務給員工B。這樣的方式會導致你浪費時間在那邊空等。

那如果你理解發包的精微,使用async的方法發包:

  1. 你叫員工A過來,請他去買午餐
  2. 此時"不等待"員工A回來,你請員工B去買飲料
  3. 也"不等待"員工B回來,你去找員工C討論事情

等員工A和B陸續買回來跟你回報,因為你正在跟員工C討論,沒有浪費時間,而且員工A與B回來的時間間隔很短,便當也是熱騰騰的,因此你很開心。

統整Synchronous與Asynchronous

我們為各位整理出兩個方法不同之處的表格,給大家作為參考。

特性 Synchronous Asynchronous
概念 任務必須按順序進行,得等任務完成才能接著進行下一個 任務可以同時進行,不用等待其他任務完成
應用場景 任務間有相依性,像是文件的讀寫 任務間沒有相依性,需要提高效率和減少等待時間的任務,像是網路的請求
複雜度 較低,好懂和測試 較高,需要處理像是Promise
資源使用率 較低,可能會等待 較高,可同時進行多個任務
延遲時間 較高,需要等待所有任務完成 較低,可以即時回應
錯誤處理 較好處理 比較不好處理,需要從Promise或平行處理中抓到錯誤

總結

Synchronous與Asynchronous各自有合適的場景與使用時機,不見得哪個就一定最好,哪個就最差,要視情況、資源以及團隊而定。

從開始寫Synchronous到兩個方法的比較,共五篇的篇幅,沒有說寫得非常好,至少能讓大家對這兩個有初步的理解就達到我的目的了!

接下來會開始講本系列文章的重點: Event Driven!
好了~~ 今天就到這邊!!


上一篇
Day 9 - Asynchronous的機制 (2)
下一篇
Day 11 - 第一階段總結
系列文
Event driven architecture的奧妙30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言